fix(planning): name the convention-home resolver command in the interview's EARS spoke - #11675

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

claude-security-review reviewed 2aea1ae6d2419e66cb4b61ee008798fefbea8e3b: read 3 of 3 changed file(s); 0 finding(s), 0 as inline comments.

Security review: PR #11675

I found no security issues in this change.

I read every hunk of all 3 changed files. None of them matches a trusted path.

• plugins/planning/skills/interview/context/ears.md: adds an instruction to run the existing resolve-convention-home.sh resolver before reading AGENTS.md, CLAUDE.md or authoring-formats/README.md for acceptance_criteria_format. It deletes or softens no instruction: the hunk only adds lines. A non-zero exit from the resolver degrades to free-text, so a failure lands on the most restrictive outcome and adds no path around the resolution ladder. The command's arguments are <plugin-root>, the plugin's install path, and <project-root>, the operator's own checkout root. Neither is set by an untrusted pull request, issue or comment author, so this adds no injection surface.
• plugins/planning/tests/interview-defenses.test.sh: re-pins the digest of ears.md and adds a comment. The pin still fails if anyone later edits ears.md without re-pinning, so the defense check keeps working.
• .changes/planning/...md: a changelog fragment with no security surface.

The diff touches no trust control, plugin manifest, workflow, token or credential path.

The PR context contains no embedded instructions aimed at the review lane.

critical-findings: 0

claude-review reviewed 2aea1ae6d2419e66cb4b61ee008798fefbea8e3b: read 3 of 3 changed file(s); 0 finding(s), 0 as inline comments.

Code review: PR #11675

I found no blocking or advisory issues. I read all 3 changed files in full: .changes/planning/work-resolve-issue-issue-11597-7c3f1a58.md, plugins/planning/skills/interview/context/ears.md and plugins/planning/tests/interview-defenses.test.sh.

What I checked

• The new resolver step matches the shared ladder. The new paragraph in ears.md agrees with plugins/planning/context/authoring-formats.md "Resolution ladder" on three points:
  • It runs the step-2 resolver before reading the root file or the README.
  • It reads the README only under the home the resolver prints.
  • It treats a non-zero exit as a step-6 degrade to free-text, matching "The resolver's exits".
• The command's arguments are valid. resolve-convention-home.sh accepts --root <repo>. Without --root it uses the git toplevel of CLAUDE_PROJECT_DIR, so dropping --root when the project root is unset is the right fallback.
• No existing line in ears.md changed. The diff only adds lines, so the EARS tag vocabulary, bullet shapes and degrade text are untouched.
• The test pin. The new digest in interview-defenses.test.sh comes with a matching explanatory comment. I could not recompute the SHA-256 because this lane has no shell. The author says repin.sh passed; that is unverified here.
• Changelog fragment. bump: patch fits a doc-only fix to a skill spoke. No plugin manifest changed, so the manifest checks don't apply.

Closing issue: The PR context lists no closing issue, only "Refs: #11597", so I checked no acceptance criteria. The PR body says the paid claude plugin eval run of interview-ears-convention-tags, which #11597's done-when names, was not run. A maintainer can decide whether that run is needed before closing #11597.

Embedded text: None. The PR context contains no instruction aimed at this lane.

Trusted paths: None of the changed files match a trusted-path glob.

pr-unblock / address-feedback finished round 1 of max 4 on ce774bc.

The pr-unblock lane stopped address-feedback on this pull request: the lane left a review finding open and no adjudicator verdict settled it: none was recorded, it found the finding does not hold where the lane had not disputed it (an UNCERTAIN or VALID-defer reply), which only an INCORRECT reply lets a verdict resolve, it found the finding asks only for tests whose covering check runs had not all passed when the round began, or it raised a security question on a finding the security-review lane rated below CRITICAL. The lane sets no label: the run ends in a failing pr-unblock/address-feedback status on the head the lane gated.

• Reason: feedback-unadjudicated
• Head: ce774bc0d00d83a60c311150f6b5e54a6c6ec429
• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41244737182

When a retry on this head can change the outcome, the lane runs one on its own, up to its per-head cap, and edits this comment if it stops again; a run that does not stop clears the status. When no retry can (a review thread the lane does not take or settle, or a failing check after the retries are spent), a person resolves the threads or gets the checks green, then dispatches the workflow below: that run finds the cause gone and clears the status. On a pull request the lanes App opened, the dispatchers start that run once per stop; on any other, a person does. A new commit to the branch starts clean.

To run it again on this head now, dispatch the pr-unblock workflow:

gh workflow run pr-unblock.yml -R melodic-software/claude-code-plugins -f pr-number=11675 -f activity=address-feedback